APPENDIX D: 
Marked copy of amendments to specification 

Please amend the paragraph on page 1, lines 7-9 (first paragraph) as follows: 

This invention relates generally to wireless interface technology and, more 
particularly, relates to the interface between computer software applications and wireless 
devices operating in accordance with the BLUETOOTH [Bluetooth] wireless protocol 
specification. 

Please amend the paragraph on page 2, line 13 through page 3, line 5 as follows : 

Radio frequency links solve many of the problems inherent in Infrared links, 

however, a radio frequency connection scheme is needed whereby a variety of applications 
can easily access the radio link through a connection mechanism that provides an appropriate 
interface. One protocol which defines communication between wireless devices through 
radio frequency links is the BLUETOOTH [Bluetooth] specification. BLUETOOTH 
[Bluetooth] devices do not require a line of sight with one another to operate, and their range 
can be significantly greater than that of IR links. However, one difficulty with the 
BLUETOOTH [Bluetooth] specification is that very few computer software programs are 
written to communicate with BLUETOOTH [Bluetooth] compliant devices. Another 
difficulty with the BLUETOOTH [Bluetooth] specification is that BLUETOOTH 
[Bluetooth] compliant devices are presented to computer software programs as serial 
interfaces. There are [be] numerous situations it which such a serial presentation can be 
inefficient or even confiising for certain types of computer software applications, such as 
simple networking applications. Yet another difficulty with the BLUETOOTH [Bluetooth] 
specification is that, while it supports up to 30 emulated RS-232 ports, computer software 
programs are generally required to know how to communicate through such an emulated port 
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in a device-specific manner. 

Please amend the paragraph on page 3, lines 8-13 as follows : 

Accordingly, the present invention provides a method and computer program product 

for providing an interface to a BLUETOOTH [Bluetooth] compliant device which can 
emulate a modem such that computer software programs can communicate through the 
BLUETOOTH [Bluetooth] compliant device in the same manner in which they would 
communicate through a standard modem to access a dial-up, wide area network. 

Please amend the paragraph on page 3, lines 13-18 as follows : 

The present invention also provides a method and computer program product for 

providing an interface to a BLUETOOTH [Bluetooth] compliant device which can emulate a 
network socket such that computer software programs can communicate through the 
BLUETOOTH [Bluetooth] compliant device seemingly in the same manner in which they 
would communicate through a standard network interface card to access a local area 
network. 

Please amend the paragraph on Page 3, lines 18-19 as follows : 

Additionally, the present invention provides a method by which the interface to a 

BLUETOOTH [Bluetooth] compliant device is dependent on the nature of the 
BLUETOOTH [Bluetooth] compliant device. 

Please amend the paragraph on page 10, lines 11-20 as follows : 

According to the "Specification of the BLUETOOTH [Bluetooth] System" Version 

l.OB (December 1,1999)5 incorporated herein by reference in its entirety, RFCOMM 
supports up to 30 emulated RS-232 (COM) port connections between any two devices. See 
also the "Windows Wireless Architecture" presentation at Appendix B, the " BLUETOOTH 
[Bluetooth] Architecture Overview" presentation at Appendix C, the " BLUETOOTH 
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[Bluetooth] Experience in Windows" presentation at Appendix D, and the " BLUETOOTH 
[Bluetooth] Stack in Windows" presentation at Appendix E. However, Dial-Up Networking 
(DUN) connections provide specific services that are best presented as a modem. 
Accordingly, when a DUN profile is exposed as a COM port rather than as a modem 
connection, the relevant client application must have the ability to communicate in a device- 
specific way with a device. 

Please amend the paragraph on page 10, line 21 through page 11, line 4 as 
follows : 

In keeping with an embodiment of the invention, DUN services are exposed by 
RFCOMM to the application as a modem connection, allowing the client application to use 
standard Telephony API (TAPI) and Unimodem interfaces. Thus applications and services 
which are not specifically adapted for use within the BLUETOOTH [Bluetooth] protocol can 
nonetheless utilize a communications device as a standard communications device, hiding 
the implementation-specific differences between BLUETOOTH [Bluetooth] and Dial-up 
Networking connections. 

Please amend the paragraph on page 11, lines 5-17 as follows : 
RFCOMM is implemented as described in the "Specification of the BLUETOOTH 
[Bluetooth] System" Version LOB Part Fl entitled "RFCOMM with TS 07.10 incorporated 
herein by reference in its entirety and attached at Appendix A, with certain changes to effect 
the desired functionality. The following components, most of which appear in the 
architectural diagram of Fig. 3, are used to expose a BLUETOOTH [Bluetooth] RFCOMM 
Dial-Up Networking connection as a modem rather than as a COM port: RFCOMM.SYS 
(the BLUETOOTH [Bluetooth] RFCOMM driver) 301; BTHPORT.SYS (the BLUETOOTH 
[Bluetooth] port driver implementing L2CAP and HCL) 303; TDI (transport device 
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interface) 305; PnP (the "Plug'NTlay" system); BTHMDM.SYS (the BLUETOOTH 
[Bluetooth] modem driver) 307; and MODEM.SYS (the Unimodem driver) 309. As one of 
skill in the art will know, the Plug*NTlay system is a combination of hardware and software 
support that enables a computer system to recognize and adapt to hardware configuration 
changes with little or no user intervention. 

Please amend the paragraph on page 11, lines 18 through page 12, lines 2 as 
follows : 

When a new device conforming to the BLUETOOTH [Bluetooth] specification is 
detected by the computer, BTHPORT.SYS enumerates the new device as a Physical Device 
Object (PDO). As is known by those of skill in the art, a PDO represents the whole range of 
functionality available to a component. RFCOMM is alerted to this new device by way of 
BTHPORT.SYS. RFCOMM. SYS is loaded as the Functional Device Object (FDO) by the 
Plug'N'Play system (PnP). As is also known by those of skill in the art, an FDO represents a 
set of functions of device available to a function driver. 

Please amend the paragraph on page 12, lines 3-1 las follows : 
RFCOMM examines the Service Discovery Protocol (SDP) database of the remote 
RFCOMM device. If the remote device is a DUN device, RFCOMM enumerates a new 
PDO. For BLUETOOTH [Bluetooth] LAN access points and PC's acting as LAN access 
points, RFCOMM. SYS enumerates a PDO that will load an instance of a Null modem device 
in BTHMDM.SYS. For BLUETOOTH [Bluetooth] modems acting as a Gateway (GW), 
RFCOMM.SYS will enumerate a PDO that will load an instance of a modem device in 
BTHMDM.SYS. BTHMDM.SYS communicates to RFCOMM using 10 request packets 
(IRP's) via the TDI interface. Alternatively, BTHMDM.SYS may communicate with IRP's 
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that are not restricted to TDI requests, but that are still Windows Driver Model (WDM) 
requests. 

Please amend the paragraph on page 12, Une 17 through page 13, line 2 as 
follows : 

To permit peer-to-peer DUN communications between two PC's, it is preferable that 
one of the PC's acts as a server. The server PC preferably populates its SDP database with 
and appropriate DUN entry so that the client can identify and connect with it. This is 
preferably performed at the time that the RFCOMM driver loads, either at system start up, or 
at the time that the BLUETOOTH [Bluetooth] device is connected to the system. 
RFCOMM. SYS will automatically generate a PDO to represent the server channel to 
BTHMDM.SYS, such that the server software may be initialized and ready to handle an 
incoming connection request. 

Please amend the paragraph on page 13, lines 8-10 as follows : 
The communication mechanism described above with reference to BLUETOOTH 
[Bluetooth] DUN connections also applies to dependant profiles such as the LAN access 
profile and the FAX profile. 

Please amend the paragraph on page 15, line 11-23 as follows : 
Existing implementations of the BLUETOOTH [Bluetooth] specification map remote 
devices to a generic serial-type device. Unfortunately, proper configuration of such a system 
requires user knowledge regarding serial port technology. In an embodiment of the present 
invention, RFCOMM connections of a particular type are automatically routed to an appropriate 
corresponding device type within the Microsoft brand WINDOWS operating system using the 
SDP. Broadly, if a device is not a DUN device, then RFCOMM will allow access to that 
device through the TDI interface. This access is extended to user mode by AFD.SYS (standard 
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Winsock service provider for transports). In order to allow TDFs addressing model to multiplex 
multiple connections to the same RFCOMM channel on different RFCOMM sessions, the 
RFCOMM channel number/remote BLUETOOTH [Bluetooth] address pair of the endpoint 
uniquely identifies each RFCOMM connection. In contrast to the DUN profile, Winsock and 
AFD will be required to create device objects and handles in a mechanism consistent with 
existing TDI applications. 
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